1. Technical Field
The present invention relates to data processing systems, and further to a method and data processing system including a logical volume manager. More particularly, the present invention provides a method and data processing system for configuring a device type or device subtype to allow an application to control behavior changes via the device type or device subtype.
2. Description of Related Art
Direct access storage devices (DASD) are widely used in mainframe computer systems to store data. In order to manage these direct access storage devices, several disk management techniques are currently available. One useful and popular technique is logical volume management. Instead of interfacing directly with a physical partition on the direct access storage device, a logical volume manager (LVM) divides the disk space on the drive into logical partitions. A logical partition may include several direct access storage devices but is transparent to a user. In other words, the logical partition appears as a single storage device to the user.
At the lowest level of logical volume management is the physical direct access storage device itself. Each individual direct access storage device is formatted into a physical volume (PV) for use by the LVM. Each physical volume has a name and belongs to a volume group (VG). A volume group is a collection of direct access storage devices under the management of the LVM that are treated as a single large storage area. All physical volumes within a volume group are divided into physical partitions (PPs) of a certain size. These physical partitions are allocatable units of disk space, typically on the order of 2 megabytes or 4 megabytes. The total number of physical partitions on each direct access storage device varies and depends on the total capacity of the direct access storage device.
Each volume group defines one or more logical volumes (LVs). Logical volumes are groups of information located on physical volumes. Although data on a physical volume can be discontinuous, the data on a logical volume appears to the user as contiguous. This arrangement permits file systems, paging space and other logical volumes to be resized or relocated, span multiple physical volumes and have their contents replicated for greater flexibility and availability in data storage.
Multiple logical volumes can be created for each volume group. Creating a logical volume requires certain information to be entered into the logical volume manager. For example, the LVM requires that each new logical volume have a specified file system type. The specified file system type is stored in the logical volume control block (LVCB), which includes in-band data (data located within the logical volume) of the LVM. The logical volume control block is the first 512 bytes of a logical volume.
The LVCB contains information such as the creation date of the logical volume, information about mirrored copies, and possible mount points in the journaled file system. Once a logical volume is created, the device type or subtype specified for the particular logical volume cannot be changed for the life of the logical volume.
Although the LVM allows storage drive space to be added or expanded while the system is running, applications have traditionally skipped over the LVCB area when laying down data. Applications exclude the LVCB area when writing data in order to retain the configuration information contained within the LVCB. However, the configuration information stored in the LVCB may not be critical information and may be overwritten without negatively affecting the LVM.
One problem with excluding the LVCB from being written over is that skipping over the LVCB area causes alignment problems with the underlying physical storage. For example, a logical volume manager may use striped logical volumes to increase I/O efficiency. Striping spreads the consecutively ordered data, such as a file, in a logical volume across several disk drives, in such a way that the I/O capacity of the disk drives can be used in parallel to access data on the logical volume. In a striped logical volume, the data addresses follow the sequence of stripe units rather than the data blocks themselves. A complete stripe consists of one stripe unit on each of the physical device that contains part of the striped logical volume. Excluding the LCVB when using striped logical volumes can create alignment problems when writing to more than one device, for example, if an application skips 4K at the beginning of the logical volume and then performs a 64K write/read on the striped logical volume. The application will write/read 60K from a first disk, and use a second disk to service the additional 4K. If the 60K and 4K writes are not serviced at the same time, data within the block may become inconsistent between the 60K write and the 4K write.
Another problem with preventing the overwriting of the LVCB is that the application does not know where to start laying down its own data. For example, if the LVCB data is to be retained in the first 4K of the logical volume and the LVCB needs to be updated to reflect a move in data storage from one location to another, the offset for the logical volume will be set to zero in order to allow the application to write over the LVCB. Since the application traditionally skips the LVCB area, having the offset switched to zero and writing over the LVCB data will cause the application to think that its data is corrupted.
Thus, it would be advantageous to have a method, system, and apparatus for allowing the specification of a new device type and device subtype to indicate to an application that the application does not need to skip over the LVCB. It would also be advantageous to have a method, system, and apparatus for using the new alternate device type and subtype to signal to an application to behave in a new way. Moreover, it would be advantageous to allow an application to supply a new alternate device type or subtype in order to manage and control behavioral changes via the device type or subtype.